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1. BACKGROUND 


Our compilers generate references to hundreds of “hidden” names — runtime routines, special 
external variables, and the like. Neither our applications nor our users’ programs may define a 
publicly-visible name that conflicts with one of these hidden names, because that would break the 
associated language function. 


Furthermore, in mixed-language programs, no hidden name used by one language may conflict 
with a hidden name used by another. With the advent of CMERGE and Windows, mixed- 
language programs are becoming quite common; for example, any FORTRAN program now 
contains runtime code written in C and Pascal as well as the main program in FORTRAN. 


Looking to the future, we might want to guarantee that there are no conflicts with hidden names 
defined for particular environments, like XENIX,. Windows, or DOS. As our products become 
more highly integrated, we may also want to prevent conflicts across applications. 


Up to this point, each product development group has insured that there are no name conflicts in 
its products. There has been little need for communication between groups on this issue. Now 
that products are being merged, the possibility of naming conflicts is significantly greater, and it’s 
unlikely our testing regimen will uncover all such conflicts in all possible combinations of 
products. 


By adopting a naming convention now we can reduce the chance that naming conflicts will arise 
in the future. 


This document contains: 
e A naming convention for hidden names. 
e Instructions for using the convention to devise new names. 
e A list of exceptional names that must be avoided. 
e The history of this particular convention. 


e Ashort list of pitfalls for the unwary. 


2. THE NAMING CONVENTION 


1. This convention applies only to “hidden” names. 


Documented user-visible names, such as many conventional C library routines, need not 
follow it. There is always the possibility that user-visible names may clash; this possibility 
can be minimized by following this convention for new user-visible names. (I have some 
reservations about recommending such a policy.) No public name should have the form of a 
hidden name unless it meets all the requirements of this convention. 


2. Everyone should follow this convention. 
If a product is released with non-conventional names, later we may not be able to integrate 


it with another product and retain upward compatibility. Following this convention should 
make integration easier and less risky. 
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3. A hidden name for a given language or environment begins with a prefix that is unique to 


the language or environment. 


The following table defines the prefixes: 


Common to All 

BASIC __b 

C c 

COBOL k 
DOS 

FORTRAN 

Pascal 
Windows 
XENIX 


Note that if you are programming in C, the nameea will begin with juat one underscore. Also 
note that letter case ts significant. For comments concerning the "Common to All” case, see 
“PITFALLS” below. 


Within a given inngunee or environment, the rules for devising names are up to the group 
responsible for the language or environment. 


A group may elect to follow additional conventions for the portion of a hidden name after 
the prefix. For example, the name could be based on Hungarian, or on the memory model, 
or on the version number of the associated product. It may also be reasonable not to follow 
a convention at all. Such matters are beyond the scope of this document. 


A hidden name must not appear in the list of exceptions. 


The exceptions are listed in section 4. Each exception is a name that already exists 
somewhere in the runtime of a language or environment. By avoiding these names we 
protect upward compatibility and reduce our future software maintenance effort. 


If necessary, a group must establish its own policy to insure that there are no name conflicts 
within a given product. 


3. USING THE NAMING CONVENTION 


When you need to devise a new name, do the following: 


1. 


Select a name, based on the prefix appropriate to your product and any special conventions 
internal to your group. 


Verify that the name does not appear in the list of exceptions. If it does, you must choose 
an alternative name. 


Take whatever actions are necessary to insure that no one else in your group has also 
chosen that name. 
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The following names are already in use in by at least one language or environment. They must 


be avoided when selecting new names, either hidden or public. 


Please note that in C, these 


names would be written with a single leading underscore, and letter case ts significant. 


__3to4 

~~ ABCDEFGHIJKLMNOPQRSTUVWXYZ abedefghijklmnopqrstuv wxy 20123456789 

_AMP _AST __AT _AUTO _Acttab 
__BAR ~__BASENAME_ __BLNK _ __BLNK__ __BRA 
__BREAK __BSL BSS _BUFSYNC __Bit 
__o CBR CKT CSTART __DATA 
__DEFINE _DIG __DOL1 __DOL2 __DORIGIN 
__DQU EDATA __EF __END __EOF 
__EOR __EQ ETEXT FBSS _FDATA 
__FILENAME FILE__ _FOR __GT __HAT 
__IDCH __ID_ __IF __IOEOF __IOREAD 
__IORW __IOWRT _KET __L __LINE__ 
__LPC __LQU __LT _MAIN _MAIN__ 
__META __MIN __MIN_BLKS _N NFILE 
__NUM _O _ OPTIONS Objent Objtab 
__ Objtmp Objval __P __PCS _PLS 
__POP _ __ QU __ RETURN _S __5SEM 

_SH_ __SORIGIN __ SPC START __Sigtramp 
_Spacct __Syspe __TAB _TEXT __TORIGIN 

__TTY __TV __TVORIG __U __UNIvee 
__UPC __V __ WHILE aso 22m 
__acsjmptab __ active __addr __adm __ advance 
__aintr __aldiv __ alloca almul __alrem 
_—_alshl __alshr __20p__ __arg __asnjmptab 
__ assert __at __atn2jmptab __atnjmptab __auldiv 
__aulmul __aulrem __ aulshr __b __ base 
__bdevent __bdevsw __ bits __blanks __Dbidiv 
_—blkptr __bimul __ blocks __blrem __blshl 
__bishr __ bool _ __ braelist __branch __braslist 
__.bravar __brketl __buf __bufend __bufendtab 
__bufsyn __ bufsyne __buldiv __bulmul _bulrem 
__bulshr __ byte __bytptr __¢_clea __e_why = 
__ callout _catch __.cclass __cdir __cig 
__cheat chk_ty __chklin __chkstk __chkstk4 
__cksum __cleanu __cleanup __Cclearh __clearl 
__¢lock clreol __cnot __combop __compha 
__comptr __con_tty __cond __const _..coremap 
__coshjmptab __cosjmptab __cost_f __countb __countbase 
__counte __countend __cron __cropzeros __¢t 
__ctrandisp] __ctrandisp2 __ctype __ctypel __ctype2 
__cty pe _ __curproc __cursize __evt __cwd 
cyt __d __ date __ date _ __ day 
__days __dbargs __dbsube __dbsubna __devtdisi 
__devtst0 __devtst0a __ debug __ delay __delcha 
__dellin __devclo __devent __devope __devrea 
__devew __devwri __dir __divO __dmovtmpessi 
__doexee __doprat __dorigin “ __doscan __dosioctl 
__dospawn __dosret0 __dosretax __dtab __.dtoxmode 
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___dtoxtime __dumpdev __ec_qui __echoit __edata 
__end __ endope __endopen __endwin __ entry 
__eofflag __eptr_ __eqname __err __ error 
__errormsg etext __ execute __ exit __expjmptab 
__fac __fassign __f{buf __femp __fesp 
__fctmp __fetopst __ffexpm1 __ffree __filbuf 
__ file __ filename __find __findbu __findfi 
__findio __findiop __first _ __ fiscal ___fixdel 
__ fixup __ flag __fisbuf __fitin __ fitout 
__fitused __fmalloc __fmode __fmsize __fndptr 
__foum _ __foo __foredecpt __forceh __forkptr 
__forptr __fpemulator __fperr __fpinit __fpmath 
__fpsignal __lptaskdata __fptostr __fptrap __freebuf 
__ftbuf __ftime __ftoi __ftol __gd_cnt 
__gdstat __gdstra __gdtab __gdup __gdutab 
__getecl __getrnge __getst __getstream __gtstat 
__gttab __ heap __help __hIlmode __hmstat 
__hmutab __hpstat __hputab __hsstat __hstab 
__htclos __htstat __htstra __httab __i 
__i_size __id_cha __id_lin __ifile_ __ifptr 
__imok __in_ __ indefinite __infinity __init 
__init_e __init_k __innum ___inode __input 
__inscha __inslin __ insmod __instr __ intr 
__io2_ __i03 _ __io_ __iob __iob2 
__iobuf ___iomode __isindst __kdsa __kdsd 
__kisa  __kisd __kLtty __kpmode re | 
__lastbu __lastbuf __lastdate __lastiob ___lbolt 
__ldhead __lIdiv __lib __line_a __line_f 
__ll_mov __ll_ref __Imul __Injmptab __Inkerr 
__lnum _ __locl __logemax __logjmptab __logn _ 
__!Ipdays __|ptr_ __lrem __Ishl __Ishr 
__lstptr __ main ___maperror __mapit __mausmap 
__ max __mba_cnat __Mmbaef __mbadev __meount 
__membrk __ mount __move __msginfo __ msgque 
__msgtab __mtab — __multi __2 __D_D 
__n_name __n_optr __b_offset __D_zeroes __bhame 
__hame _ __hamef _ __nhamptr __nargs __new_tt 
__nOfree __hite __nmalloc __hmsize __ nogud 
__asbrk __hswap __ bull _ __bullsy __ object _ 
__ objectq _ __ Offset __ofill __ogetf __ ogetv 
__op __ openfile __openi __oprt __oread 
__oserr __ osfile __osmajor __osminor __ out _ 
__outch __outcha __ output __ova __ovd 
__ovél __Panicstr __Pparptr __ pause __pbottom 
__pbuf _~—period __pPfast __pPfile _—piby2 
__Pickup __ pipe __pipedev ___ pos __ positive 
__ post _—_pre __pre_addr _—pre_cat _—print 

__ proc __ profil _—_prs __ Psp _—_Pptacct 
__ptr __ptrandispid __ptrandispls __ptrandisp2d _—Pptrandisp2s 
_—putcha __putchar _—pwr_clr __rawmod __tawmode 
__te __rdtrd __treadop __ reason __req_ 
__res_fl __tes_fig _._ reset __tfstat __ftab 
__tkstat __tkstra __rktab __ti_ent __tlatof 
__rifitpr —__Tiprint __Tistat __titab __rootdev 
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__tpop __rpstat __rpstra __tptab __rpush 
__tbignan __rtchsifneg __rtifprojnpop __ftifprojpop __rtiadfnpop 
__ttindfpop _._ttinfopop __rtinfpop __ttnospop __rtnospopde 
__ltonenpop __rtonepop __lttosnpop __Ittosnpopde __ttospop 
__!ttospopde __rtzeronpop __Itzeropop __sbmap __Sbrk 
__58brkslop __Ssbrpte __sbuf __.secsid __scrdow 
__seroll __8ctab __Sdget __.sema __seminfo 
__.setbul __setdta __sethl __setmod __setwin 
__shmem __shminfo __shove __showst __sibuf 
__sinhjmptab __.sinjmptab __ size __smbuf __8movtmpessi 
__sobuf __.sorigin __SP_ __5par __ sprint 
__sprintw __sqrtjmptab __sscans __8t __ Start 
__Statefile __stbuf __stdbuf __stime __Sstkgro 
__stmax __ stop __ string __Sstringq _ __Sstrinit 

__ Strout __subop __sum __ super0 __superl 
__Swapdev __8wapmap __swhbuf __swbufl __swbhuf2 
__.8Wwplo __synemo __ syscal __8Y8err __sysinfo 

__ sysname __tanhjmptab __tanjmptab __ tbls __text 
__time __tmclos __tmp __.tmstat __tmstra 
__tmtab __ token __tolower __torigin __toupper 
__trandisp] __ trandisp2 __trap __tscrol ___tsstat 
__ttread __ttstat  __ttwrit __tty __tty_ch 
__tvorig __tzflag __u __uba_ent __ubacf 
__uldiv __ulmul __ulrem __ulshr __umaskval 
__umemvad __unctrl ___user __ userid __utsname 
__UUuD_ __Vv __var __ verify __ wait 
__whptr __Wwin __ window __writec __wrtchk 
__wtmp an __x25info __xcend __xcleanup 
__xestart __xed _ __xfisbu __xfune __xiend 
__xistart __xpop __xpush __XXXX __ytoxjmptab 
~~yystype_ 

5. HISTORY 


For the past few months, a group of people from Operating Systems and Systems Languages have 
been discussing the naming conflict problem and the possibility of adopting a naming convention 
to solve it. 


The simplest approach seemed to be a convention in which names are unique to each product - 
that is, they are somehow qualified by the product name. If the qualification could be guaranteed 
not to conflict with any existing name, the convention could be implemented very easily. 


Furthermore, if special names began with a character that users were unlikely to choose for their 
own names, we could minimize the possibility that a user’s symbol would accidentally collide with 
a hidden name. 


The first naming convention proposal suggested using a dollar sign at the beginning of each 
hidden name, and modifying the compilers to allow dollar signs to begin names. Unfortunately 
the dollar sign causes grave problems for a number of utility programs, including some assemblers 
and debuggers. Even more unfortunately, almost all the other special characters caused worse 
difficulties. : 


Consequently, we resorted to the underscore, which was already in use for a similar purpose. 
Because C already uses a single underscore for all public names, we decided to use two. The 
qualifier for a name would consist of two underscores followed by a single character identifying 
the associated product. 
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Since there was the possibility that names with this form might already exist, we gathered 
namelists from existing products and libraries to form the “exceptions” list. No name appearing 
on the exceptions list may be used for a new purpose, because a conflict might arise. 


After a review by group leaders and other members of the development staff, we put the naming 
rules and exceptions list into this document for distribution. 


6. PITFALLS 


It is possible that some existing names in different products may already conflict. Where possible, 
we should revise such names to follow this convention. Full upward compatibility may preclude 
this possibility. If so, resolution of such problems is beyond the scope of this document. 


Although there is a category for names which are “common”, it is not at all clear what criteria 
should be used for classifying such names. Furthermore, there are technical issues to be resolved, 
such as calling protocols for “common” library routines. If anyone is interested, this might be a 
good topic to pursue. 


Another problem is the type and number of significant characters in a name. Microsoft's systems 
products allow very long names with many significant characters, but we can’t guarantee that 
they'll always be used. (For example, we have OEMs that have ported our compilers to other 
environments for cross-development.) Underscore characters or long names may cause problems 
for foreign linkers. If you're particularly concerned about portability, you should restrict your 
external names to six characters, including the three-character prefix. If you're cautious but not 
fanatical, you should restrict your external names to the eight characters supported by moat 
versions of UNIX. A macro preprocessor can be used to remove the underscores if necessary. 
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